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DYNAMICALLY LOADING PROGRAM CODE OVER A PUSH-BASED 

NETWORK 

Field of the Invention 

The invention generally relates to pushing programming code over 
5 unidirectional communication links, and more particularly, to pushing dynamically 
loadable program code, such as an object-oriented class definition, over the 
unidirectional communication link. 



Background 

10 FIG. 1 illustrates a general prior art hardware environment for pushing data 

to a receiving computing device. 

As illustrated, there is a data-pushing device 100, such as one or more 

network servers or other computing devices, that pushes data onto a network 102. 

The data-pushing device is responsible for generating or forwarding data that is 
15 ultimately received by a receiving computing device 104. The network can be any 

combination of conventional and proprietary networks such as an intranet or the 

Internet 

A receiving computing device 104, also in communication with the network, 
receives the pushed data. Various protocols for receiving pushed data are known 
20 in the art. For example, see the PointCast system by EntryPoint of San Diego, 
California. Generally, the receiving computing device 104 listens to a particular 
data channel, e.g., a Transmission Control Protocol/Internet Protocol (TCP/IP) 
network port, broadcast channel, frequency range, etc. for data pushed by the 
data-pushing device 1 00. 

25 
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consumption, a class can be dynamically loaded and unloaded to conserve 
resources. 

As will be discussed below, dynamic loading can be effected over a push- 
type of networking environment. For example, identification data of a class can be 
5 announced according to the Service Advertising Protocol (SAP) / Session 
Description Protocol (SDP) protocol, and the class definition broadcast 
accordingly. Alternatively, a manifest can be defined that contains identifying 
data for the definition of a class, and a schedule indicating when a second push 
will be made that contains the actual program code for the identified class. A 
1 0 programming environment and/or application program can then use a custom 
class loader to integrate, when needed, pushed classes. 

In this description and claims that follow, the term manifest is intended to 
include both transmission of a manifest, or a SAP/SDP type of announcement of 
its contents. 

15 

FIG. 2 illustrates a variation on the FIG. 1 push environment, in which the 
network 102 includes wireless networks. Wireless networks include short-range 
wireless networks including wireless LAN bridges/routers, Bluetooth (a standard 
promoted by 3Com, Ericsson, Intel, IBM, Lucent, Microsoft, Motorola, Nokia, and 
20 Toshiba), or the like, and long-range wireless networks such as microwave 
systems, satellite systems, cellular communication systems, television 
transmission towers, etc. 

In one embodiment, wireless transmitters comprise a complete transport 
data pathway between a transmission tower 204 and a receiver, such as a set top 

25 box 208, personal digital assistant, portable computer, handheld computer, 
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wireless appliance, or other receiving device. In another embodiment, the 
wireless signal is partially carried on a physical medium, such as a wire, fiber 
optic, or other medium, before being received by the set top box 208. Network 
206 may or may not be entirely wireless. 
5 Assuming the wireless transmission is an audio and/or visual signal, such 

as a television signal, a transmitting device 200, which may be a computer or 
other device providing television signals, transmits multiple television data 
streams to a multiplexer 202. For example, in digital television, Moving Picture 
Experts Group (MPEG)-2 data transport streams would be emitted from the 
10 multiplexer. A transport stream comprises multiple elementary streams of audio, 
video, and/or other "data" that is multiplexed and marked with a packet identifier 
(PID). Under the United States Advanced Television Systems Committee (ATSC) 
digital television standard, a single "channel" is allotted 19.2 Mbps bandwidth. A 
single television program typically comprises elementary data streams for video 
15 and each supported audio language. With data compression, the program may 
not consume all available bandwidth for the channel, so the program may become 
one of several "virtual channels" embedded within the physical spectrum allotted 
to a broadcaster. 

The multiplexer combines these multiple data streams into a single 
20 transmission that is transmitted by a tower 204. This transmission is sent over a 
network 206, and received by a set top box 208, such as a cable television 
decoding-box, computer device with a television decoder, or other television- 
aware device. 
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FIG. 3 is a flowchart, according to one embodiment of the invention, for 
pushing programming code, such as dynamically loadable program code, over a 
unidirectional communication link such as illustrated in FIG. 1 or FIG. 2. 

The unidirectional communication link may be physically unidirectional, as 
5 in a transmission from a broadcast tower, or logically unidirectional, as in a 
unidirectional communication protocol. It is assumed herein that programming 
code for Java classes is pushed to a receiver. However, the disclosed principles 
and techniques are equally applicable to Objective-C, C++, SmallTalk, Modula-3, 
Component Object Model (COM), and other object oriented programming 
10 languages and environments, and the invention is not limited in this respect. It will 
be appreciated by one skilled in the art that other data structures, besides classes, 
may be pushed as well. For example, a Dynamic Link Library (DLL), or 
equivalent, having known entry points and structure may be used. 

In an object oriented programming environment such as Java, a class 
1 5 encapsulates data, methods and procedures that operate on data input to an 
instance of the class, and produce appropriate output. Classes are usually 
collected into libraries for solving particular problems. Java libraries are called 
"Java archives," or JAR files. To minimize memory requirements and facilitate a 
more dynamic programming model, Java execution environments defer loading a 
20 class into system memory until the class is utilized by an executing application 
program. 

When a class is referenced, if it is not already loaded, it is dynamically 
loaded and made available to an executing program. Loading requires that a 
standard location (or locations) be searched for the references class, e.g., to 
25 locate a JAR file or other storage of class definition. In Java, an environment 
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variable (or equivalent) called "CLASSPATH" is expected to exist and indicate a 
search path for locating class definitions. For example, CLASSPATH may point to 
directories/folders containing class definitions and/or JAR files, or directly 
reference a data file storing archives therein. If a class cannot be found and 
5 loaded after searching the CLASSPATH environment, loading fails and the 
corresponding call within the application program fails. 

Thus, in one embodiment, to load dynamically loadable program code over 
a push-type networking environment, a manifest is first prepared 300 
corresponding to the dynamically loadable code. The manifest comprises an 

10 identifier 302 that identifies the class definition so that the class can be properly 
loaded during execution of an application program. In Java, the class definition 
identifier comprises a package name followed by a relative class name. For 
example, the "String" class is part of the "java.lang" package, and is therefore 
properly identified as °javaJang.String\ Other programming environments may 

15 utilize other identifying data, such as the name of the class, and/or a globally 
unique identifier (GUID) for the class, and/or a class context, and/or class 
dependencies. 

In one embodiment, the manifest further comprises a push schedule 304, 
or availability schedule, indicating when class definitions referenced within the 
20 manifest will be pushed onto a unidirectional communication link. In this 

embodiment the manifest may further comprise a retrieval source 306 if class 
definitions may be received on one of several unidirectional communication 
pathways. Other related data 308 may also be stored in the manifest to facilitate 
routing, verification, billing, or manifest related transactions. 
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In another embodiment, rather than utilizing a manifest, instead its contents 
may be directly transmitted over the unidirectional communication link. In this 
embodiment, an announcement may be broadcast using the SAP/SDP, or 
equivalent, which indicates an identifier and description of a session, e.g., data to 
identify dynamically loadable programming code to be pushed, a location from 
which the code can be retrieved, e.g., a multicast addresses / port for the session, 
and a schedule of when the code will be pushed. 

After creating the manifest, it is pushed 310 onto a unidirectional 
communication link. Then, in accordance with the push schedule, the dynamically 
loadable code (e.g., class) referenced by the manifest is pushed 312 onto the 
unidirectional communication link. 

FIG. 4 illustrates a receiver receiving pushed data in accordance with the 
FIG. 3 embodiment. As illustrated, the receiver listens 400 for, and receives 402, 
a pushed manifest. The manifest is parsed 404 to determine 406 identifiers for 
dynamically loadable code referenced within the manifest. These identifiers are 
stored 408 within a local memory, such as volatile or non-volatile storage. As 
discussed above, the manifest contents may be directly transmitted with SAP/SDP 
type announcements, in which case the receiver listens for announcements to 
determine identifiers for dynamically loadable code. 

A Java application program may be executed 410. When it references 412 

a class for the first time, a search 414 may be performed to locate the class, e.g., 

the CLASSPATH environment is searched. Assuming searching the 

CLASSPATH fails, a search 416 may be performed to locate the class among 

pushed class identifiers stored 408 within the local memory. If an appropriate 
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class identifier(s) is located, the schedule corresponding to the identifier may be 
inspected 418. Dynamically loadable programming code, e.g., a Java class file, 
may then be retrieved 420 from a unidirectional communication link according to 
the schedule. If SAP/SDP type broadcasting is in use, the dynamically loadable 
5 programming code may be retrieved from the multicast address / port indicated in 
the session's announcement 

In one embodiment, the retrieved dynamically loadable code may be added 
to the existing CLASSPATH environment so as to avoid future latency in utilizing 
the retrieved code. In one embodiment, the CLASSPATH comprises a 
10 combination of volatile and nonvolatile storage. In this embodiment, standard 
classes may be stored in nonvolatile storage/such as (erasable) programmable 
read-only memory (PROM), non-volatile random access memory (NVRAM), 
complementary metal oxide semiconductor (CMOS), hard-drives, memory sticks, 
etc. Retrieved code, however, may be stored in volatile storage, e.g., random 

1 5 access memory (RAM). 

Thus, for example, portable electronics, seMop boxes, or other electronics 
not configured with mass storage may be shipped with standard class definitions, 
and temporarily acquire auxiliary classes as needed during execution of an 
application program. 

20 After retrieval 420, the dynamically loadable code is loaded 422 in a 

manner customary to the program language environment in use for execution 424 
by the application program. Note that loading 422 may be performed 
asynchronously to execution of the application program causing the retrieval. 
In addition, retrieval and loading may be performed transparently by an 

25 operating system, programming environment, or the application program 
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depending on receiver environment configuration. For example, a Java runtime 
environment may determine a class needs to be retrieved 420 from a 
unidirectional communication link, and then load the class 422 without an 
application program becoming aware of the retrieval process. 

5 

FIG. 5 illustrates use of pushed dynamically loadable data to facilitate a 
pay-per-use environment. Typical pay-per-use environments include television, 
telephone, or computer network broadcast systems, where one or more 
"premium" data channels are encrypted and transmitted to a receiver, and the 

10 receiver can not use the encrypted data without obtaining a decrypting ability. 

In this illustrated embodiment, pushed manifests discussed above include 
identifiers for decryption classes that allow a receiving device to permanently or 
temporarily obtain encryption ability. The period of availability for decryption 
capability may be specified in the manifest, or regulated by local and/or remote 

15 policies. In one embodiment, temporary encryption is achieved by storing 

decryption classes in volatile memory that is cleared when a receiving device is 
reset, power cycled, etc. Clearance may also be according to a clearance 
schedule, such as hourly, daily, weekly, etc., or according to a schedule indicated 
within a manifest, e.g., automatic clearance after a certain number of uses, or 

20 after an elapsed time after first use, etc. 

Thus, a computing device, such as a set top box or portable electronic 
receiver, e.g., portable television, personal digital assistant, cellular telephone, 
portable computer, wireless appliance, or the like, executes 500 a control 
program, such as an operating system or application program. The control 

25 program receives 502 a manifest that includes an identifier and push schedule for 
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a decryption class, as well as purchasing data indicating a cost associated with 
obtaining the premium data by way of the decryption class. A user of the device 
elects 504, e.g., indicates by way of a graphical user interface, selection of a 
button on the computing device, etc., a desire to purchase the premium data in 
5 accordance with the purchasing data. In response, an appropriate purchase 
transaction occurs 506 according to the purchasing data in the manifest. 

Note that purchase transactions are intended to include purchasing 
protocols making use of third-party processing and/or billing arrangements. Since 
the communication link is unidirectional, it is assumed an alternative 
1 0 communication arrangement exists to effect payment. For example, the 
computing device may have an internal modem in communication with a 
telephone service, a network interface in communication with a network, or other 
communication pathway. Purchases may be made immediately, or performed on 
a delayed basis, e.g., the computing device receives election 504 of a purchase, 
1 5 and decryption is performed on assumption that payment will eventually be 
secured. Delayed payment facilitates using portable receivers intermittently 
connected to an alternative communication arrangement. 

After the purchase transaction 506, the computing device retrieves 508 an 
appropriate decryption class from the unidirectional communication link in 
20 accordance with the push schedule. The decryption class may be installed 516 as 
indicated by the manifest, e.g., it may be installed either permanently or 
temporarily. In a Java-type execution environment, the decryption class is 
installed within the CLASSPATH environment. The decryption class is then 
executed 512 by the control program to decrypt desired data. 
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In one embodiment, to prevent theft of the decryption class, the decryption 
class is itself encoded within a private key of a public/private key pairing in a 
public key gryptosystem. The communication device may be configured to 
contain the public key of the pairing, and the communication device decrypts the 
decryption class with the public key only after purchase transaction 506. In such 
fashion, decryption classes can be blindly pushed onto an unsecured 
unidirectional communication link without regard to illicit theft of services. 



FIG. 6 and the following discussion are intended to provide a brief, general 

0 description of a suitable computing environment in which certain aspects of the 

illustrated invention may be implemented. 

An exemplary system for implementing the invention includes a computing 

device 600 having system bus 602 for coupling various computing device 

components. Typically, attached to the bus are non-programmable and 

5 programmable processors 604, a memory 606 (e.g., RAM, ROM), storage devices 

608, a video interface 610, and input/output interface ports 612. Storage devices 

include hard-drives, floppy-disks, optical storage, magnetic cassettes, tapes, flash 

memory cards, memory sticks, digital video disks, and the like. 

The invention may be described by reference to different high-level 

program modules and/or low-level hardware contexts. Those skilled in the art will 

realize that program modules can be interchanged with low-level hardware 

instructions. Program modules include procedures, functions, programs, 

components, data structures, and the like, for performing particular tasks or 

implementing particular abstract data types. Modules may be incorporated into 

single and multi-processor computing devices, Personal Digital Assistants (PDAs) 
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cellular telephones, portable computers, handheld computers, wireless 
appliances, and the like. Thus, the storage systems and associated media can 
store data and executable instructions for the computing device. 

The computing device is expected to operate in a networked environment 
using logical connections to one or more remote computing devices 614, 616 
through a network.interface 618, modem 620, or other communication pathway. 
Computing devices may be interconnected by way of a network 622 such as an 
intranet, the Internet, or other network. Modules may be implemented within a 
single computing device, or processed in a distributed network environment, and 
stored in both local and remote memory. Thus, for example, with respect to the 
illustrated embodiments, assuming computing device 600 is a transmitter of 
pushed dynamically loadable programming code, then remote devices 614, 616 
may respectively be a set top box and a portable wireless receiver of the pushed 
code. 

It will be appreciated that remote computing devices 614, 616 may be 
configured like computing device 600, and therefore include many or all of the 
elements discussed for computing device. It should also be appreciated that 
computing devices 600, 614, 616 may be embodied within a single device, or 
separate communicatively-coupled components, and may include or be embodied 
within routers, bridges, peer devices, web servers, and application programs 
utilizing network application protocols such as the HyperText Transfer Protocol 
(HTTP), File Transfer Protocol (FTP), and the like. 

Having described and illustrated the principles of the invention with 

reference to illustrated embodiments, it will be recognized that the illustrated 
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embodiments can be modified in arrangement and detail without departing from 
such principles. 

And, even though the foregoing discussion has focused on particular 
embodiments, it is understood that other configurations are contemplated. In 
5 particular, even though expressions such as "in one embodiment," "in another 
embodiment," or the like are used herein, these phrases are meant to generally 
reference embodiment possibilities, and are not intended to limit the invention to 
particular embodiment configurations. As used herein, these terms may reference 
the same or different embodiments, and unless implicitly or expressly indicated 
10 otherwise, embodiments are combinable into other embodiments. Consequently, 
in view of the wide variety of permutations to the above-described embodiments, 
the detailed description is intended to be illustrative only, and should not be taken 
as limiting the scope of the invention. 

What is claimed as the invention, therefore, is all such modifications as 
15 may come within the scope and spirit of the following claims and equivalents 
thereto. 
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What is claimed is: 

1 . A method, comprising: 

determining whether an identifier for dynamically loadable code; 
pushing the identifier onto a unidirectional communication link; 
5 determining whether an availability schedule for the dynamically loadable 

code; 

pushing the availability schedule onto the unidirectional communication 
link; and 

pushing the dynamically loadable code onto the unidirectional 
0 communication link according to the availability schedule. 



2. The method of claim 1 , further comprising: 

wherein the dynamically loadable code comprises a class definition with an 
object oriented programming language; and 
5 wherein the identifier identifies the class definition. 

3. The method of claim 1, wherein the unidirectional communication 
link is a selected one of: a television data transmission, an MPEG-2 transport 
stream, and IP-multicast. 

0 

4. The method of claim 1, further comprising: 

receiving data over the unidirectional communication link with a selected 
one of: a set top box, a personal digital assistant, a portable computer, a handheld 
computer, and a wireless appliance. 

14 



. WO 02/48863 PCT/USO 1/43862 

5. The method of claim 1 , further comprising: 

receiving the identifier and the availability schedule over the unidirectional 
communication link; and 

retrieving the dynamically loadable code from said communication link 
5 according to the availability schedule. 

6. The method of claim 5, further comprising; 
determining whether the dynamically loadable code is required for 

executing an application program; and 
10 performing said retrieving responsive to said determining. 

7. An apparatus, comprising: 

a machine accessible medium providing instructions, which when executed 
by a machine, are capable of directing the machine to perform the operations of 
15 claim 1. 

8. The apparatus of claim 7, said instructions including further 
instructions to direct the machine to perform the operations of claim 2. 

20 9. The apparatus of claim 7, wherein the unidirectional communication 

link is a selected one of: a television data transmission, an MPEG-2 transport 
stream, and IP-multicast. 

10. The apparatus of claim 7, said instructions including further 

25 instructions to direct the machine to perform the operations of claim 4. 

15 
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1 1 . The apparatus of claim 7, said instructions including further 
instructions to direct the machine to perform the operations of claim 5. 

5 12. The apparatus of claim 11, said instructions including further 

instructions to direct the machine to perform the operations of claim 6. 

13. A method, comprising: 

preparing a manifest for dynamically loadable code, said manifest 
0 comprising an identifier for dynamically loadable code, and an availability 
schedule; 

pushing the manifest onto a unidirectional communication link; and 
pushing the dynamically loadable code onto said communication link 
according to the availability schedule. 

5 

14. The method of claim 13, further comprising: 

wherein the dynamically loadable code comprises a class definition in an 
object oriented programming language; and 

wherein the identifier identifies the class definition. 

3 

15. The method of claim 13, wherein the dynamically loadable code is 
written in a selected one of: Java, Objective-C, C++, SmallTalk, Modula-3, 
Component Object Model, and an object-oriented scripting language. 
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16. The method of claim 13, wherein the unidirectional communication 
link is a selected one of: a television data transmission, an MPEG-2 transport 
stream, and IP-multicast. 



17. The method of claim 13, further comprising: 

receiving the unidirectional communication link with a selected one of: a set 
top box, a personal digital assistant, a portable computer, a handheld computer, 
and a wireless appliance. 



10 18. The method of claim 1 3, further comprising: 

receiving the manifest over said communication link; 
recording the identifier and the availability schedule; and 
retrieving the dynamically loadable code when it is pushed onto said 
communication link according to the availability schedule. 

15 

19. The method of claim 14, further comprising: 
determining whether the dynamically loadable code is required for 

executing an application program; and 

performing said retrieving responsive to said determining. 

20 

20. A method for mirroring a Java-type archive file, comprising: 
preparing a manifest for a Java-type archive file, said manifest comprising 

identifiers for objects of the Java-type archive file, and an availability schedule for 
said objects; 

!5 pushing the manifest onto a unidirectional communication link; and 

17 
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pushing said objects of the Java-type archive file onto the unidirectional 
communication link in accordance with the availability schedule. 

21 . The method of claim 20, further comprising: 
5 executing programming code; 

determining whether an unavailable object is required for said executing; 
determining whether the manifest includes an identifier corresponding to 
the object; and 

receiving said required object over the unidirectional communication link. 

10 

22. The method of claim 21 , further comprising: 

storing said received object in a temporary memory location disposed 
within a device; 

wherein resetting the device causes said received object to be discarded. 

15 

23. The method of claim 20, wherein the manifest for the Java-type 
archive file includes purchasing data for said objects of the Java-type archive file, 
the method further comprising: 

identifying an unavailable object that is required for executing a program; 
20 determining whether the manifest includes an identifier corresponding to 

the object; 

receiving said required object over the unidirectional communication link; 

and 

purchasing said required object in accord with said purchasing data. 

25 
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24. A method for obtaining dynamically loadable code over a push-only 
network, comprising: 

receiving, over the push-only network, a manifest for dynamically loadable 
code, said manifest comprising an identifier for dynamically loadable code, and an 
5 availability schedule; and 

receiving, over the push-only network, the dynamically loadable code in 
accord with the availability schedule. 



25. The method of claim 24, wherein the dynamically loadable code 
10 comprises a selected one of: a single object oriented object, a plurality of object 

oriented object definitions, and a Dynamic Link Library (DLL). 

26. The method of claim 24, further comprising: 

determining whether an application program requires dynamically loadable 
15 code; and 

determining whether the manifest includes an identifier corresponding to 
said dynamically loadable code. 



27. The method of claim 26, further comprising: 
20 inspecting a CLASSPATH environment for a class containing said required 

dynamically loadable code; and 

determining whether said required dynamically loadable code is 
unavailable. 



25 



28. The method of claim 27, further comprising: 
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adding said received dynamically loadable code to the CLASSPATH 
environment. 



29. The method of claim 24, wherein the dynamically loadable code 
5 comprises a Java-type programming language class, the method further 

comprising: 

inspecting a CLASSPATH environment for a class containing the 
dynamically loadable code; and 

determining whether said required dynamically loadable code is 
10 unavailable, and responsive thereto, performing said receiving the dynamically 
loadable code. 

30. The method of claim 24, further comprising: 

adding said received dynamically loadable code to a local storage for 
15 dynamically loadable code. 

31 . An apparatus, comprising: 

a machine accessible medium providing instructions, which when executed 
by a machine, are capable of directing the machine to perform: 
20 preparing a manifest for dynamically loadable code, said manifest 

comprising an identifier for dynamically loadable code, and an availability 
schedule; 

pushing the manifest onto a unidirectional communication link; and 
pushing the dynamically loadable code onto said communication link 
25 according to the availability schedule. 

20 
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32. The apparatus of claim 31 , said instructions including further 
instructions to direct the machine to perform: 

receiving the unidirectional communication link with a selected one of: a set 
5 top box, a personal digital assistant, a portable computer, a handheld computer, 
and a wireless appliance. 

33. The apparatus of claim 31, said instructions including further 
instructions to direct the machine to perform: 

10 receiving the manifest over said communication link; 

recording the identifier and the availability schedule; and 
retrieving the dynamically loadable code when it is pushed onto said 
communication link according to the availability schedule. 

15 34. The apparatus of claim 31, said instructions including further 

instructions to direct the machine to perform: 

determining whether the dynamically loadable code is required for 
executing an application program; and 

performing said retrieving responsive to said determining. 

20 

35. An apparatus for mirroring a Java-type archive file, comprising: 
a machine accessible medium providing instructions, which when executed 
by a machine, are capable of directing the machine to perform: 
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preparing a manifest for a Java-type archive file, said manifest comprising 
identifiers for objects of the Java-type archive file, and an availability schedule for 
said objects; 

pushing the manifest onto a unidirectional communication link; and 
5 pushing said objects of the Java-type archive file onto the unidirectional 

communication link in accordance with the availability schedule. 

36. The apparatus of claim 35, said instructions including further 
instructions to direct the machine to perform: 

10 determining whether an unavailable object is required for executing an 

application; 

determining whether the manifest includes an identifier corresponding to 
the object; and 

receiving said required object over the unidirectional communication link. 

15 

37. The apparatus of claim 36, said instructions including further 
instructions to direct the machine to perform: 

storing said received object in a temporary memory location. 



20 38. The apparatus of claim 35, said instructions including further 

instructions to direct the machine to perform: 

including purchasing data for said objects of the Java-type archive file in . 
the manifest; 

identifying an unavailable object that is required for executing a program; 
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determining whether the manifest includes an identifier corresponding to 
the object; 

receiving said required object over the unidirectional communication link; 

and 

purchasing said required object in accord with said purchasing data. 

39. An apparatus for obtaining dynamically loadable code over a push- 
only network, comprising: 

a machine accessible medium providing instructions, which when executed 
by a machine, are capable of directing the machine to perform: 

receiving, over the push-only network, a manifest for dynamically loadable 
code, said manifest comprising an identifier for dynamically loadable code, and an 
availability schedule; and 

receiving, over the push-only network, the dynamically loadable code in 
accord with the availability schedule. 

40. The apparatus of claim 39, said instructions including further 
instructions to direct the machine to perform: 

determining whether an application program requires dynamically loadable 
20 code; and 

determining whether the manifest includes an identifier corresponding to 
said dynamically loadable code. 

41 . The apparatus of claim 40, said instructions including further 

25 instructions to direct the machine to perform: 
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inspecting a CLASSPATH environment for a class containing said required 
dynamically loadable code; and 

determining whether said required dynamically loadable code is 
unavailable. 

5 

42. The apparatus of claim 40, said instructions including further 
instructions to direct the machine to perform: 

adding said received dynamically loadable code to the CLASSPATH 
environment 

10 

43. The apparatus of claim 39, said instructions including further 
instructions to direct the machine to perform: 

inspecting a CLASSPATH environment for a class containing the 
dynamically loadable code; and 
1 5 determining whether said required dynamically loadable code is 

unavailable, and responsive thereto, performing said receiving the dynamically 
loadable code. 



44. A system, comprising: 
20 at least one processor; and 

a readable medium having instructions encoded thereon, which when 
executed by the processor, are capable of directing the processor to perform: 

preparing a manifest for dynamically loadable code, said manifest 
comprising an identifier for dynamically loadable code, and an availability 
25 schedule; 

24 



WO 02/48863 PCT/US01/43862 

pushing the manifest onto a unidirectional communication link; and 
pushing the dynamically loadable code onto said communication link 
according to the availability schedule. 

5 45. The system of claim 44, said instructions including further 

instructions to direct the processor to perform: 

receiving the unidirectional communication link with a selected one of: a set 
top box, a personal digital assistant, a portable computer, a handheld computer, 
and a wireless appliance. 

10 

46. The system of claim 44, said instructions including further 
instructions to direct the processor to perform: 

receiving the manifest over said communication link; 
recording the identifier and the availability schedule; and 
15 retrieving the dynamically loadable code when it is pushed onto said 

communication link according to the availability schedule. 

47. A system for mirroring a Java-type archive file, comprising: 
at least one processor; and 

20 a readable medium having instructions encoded thereon, which when 

executed by the processor, are capable of directing the processor to perform: 

preparing a manifest for a Java-type archive file, said manifest 

comprising identifiers for objects of the Java-type archive file, and an availability 

schedule for said objects; 

25 pushing the manifest onto a unidirectional communication link; and 
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pushing said objects of the Java-type archive file onto the 
unidirectional communication link in accordance with the availability schedule. 

48. The system of claim 47, said instructions including further 
5 instructions to direct the processor to perform: 

determining whether an unavailable object is required for executing an 
application; 

determining whether the manifest includes an identifier corresponding to 
the object; and 

1 0 receiving said required object over the unidirectional communication link. 

49. The system of claim 47, said instructions including further 
instructions to direct the processor to perform: 

including purchasing data for said objects of the Java-type archive file in 
15 the manifest; 

identifying an unavailable object that is required for executing a program; 
determining whether the manifest includes an identifier corresponding to 
the object; 

receiving said required object over the unidirectional communication link; 

20 and 

purchasing said required object in accord with said purchasing data. 

50. A system for obtaining dynamically loadable code over a push-only 
network, comprising: 

25 at least one processor; and 
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a readable medium having instructions encoded thereon, which when 
executed by the processor, are capable of directing the processor to perform: 

receiving, over the push-only network, a manifest for dynamically 
loadable code, said manifest comprising an identifier for dynamically loadable 
5 code, and an availability schedule; and 

receiving, over the push-only network, the dynamically loadable 
code in accord with the availability schedule. 



51 . The system of claim 50, said instructions including further 
1 0 instructions to direct the processor to perform: 

determining whether an application program requires dynamically loadable 
code; and 

determining whether the manifest includes an identifier corresponding to 
said dynamically loadable code. 

52. The system of claim 50, said instructions including further 
instructions to direct the processor to perform: 

inspecting a CLASSPATH environment for a class containing said required 
dynamically loadable code; 
20 determining whether said required dynamically loadable code is 

unavailable; and 

adding said received dynamically loadable code to the CLASSPATH 
environment. 

25 
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FIG. 5 
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